承上篇 ， 出處 ( 也有簡體版 ) (https://developer.mozilla.org/en-US/docs/Learn/Server-side/First_steps/Website_security)

Cross-Site Request Forgery (CSRF)

跨站 req 偽造 。 利用其他 user 未許可的憑證來執行動作 。

舉例 ： John 是個歹毒心腸的 user ， 他很懂一些已登入網站的 user 在轉帳時是使用 POST ，
而這個 req 裡面包著帳戶戶名還有餘額 ， John 建造一個藏有他銀行的詳細資訊及餘額的表格 ，
然後把他發送給網站的其他 user ( 信件帶有喬裝過的 submit button ， 上面字樣是 get rich quick 我想知道如何一夜致富 )

如果懞呆 user 點了送出鈕 ， 天～崩～地裂POST req 會傳給 server ，
裡面帶有交易詳細資料跟 browser 綁定過的 cs cookies ( 就像上次交易自動存入信用卡資料 ， 這類常見的行為 ) ，
Server 檢查過 cookies ， 判定是不是該 user 並允許進行交易 。

這個結局就是 ， 誰想知道如何一夜致富 ， 誰就幫 John 一夜致富

Note : John 不需要存取其他 user 的 cookie ， 而是交給 browser 去自動處理 ， 真聰明。

其中一種防禦是 server 審核 POST req 有沒有填入網站產生的辨識碼 ( 那些我們常見的「我不是機器人 、 請填入右圖中的英文或數字」 ) ，
這些由 server 提供的辨識碼在 user 傳送表單的時候會出現 。
這個方式可以規避 John 做的表單 ， 因為他不知道 server 會給出什麼辨識碼 ，
甚至如果他找出辨識碼 ， 進而把自製表單發給指定那一位 user ， 他也不行再用同份表單去攻擊其他 users

框架也通常有 CSRF 的防禦機制

Other threats

其他常見的攻擊或漏洞如下：

• Clickjacking
  hijack( 本日單字： hijack ) clicks ， 讓 user 點擊到藏在頁面的 routes ，
  例如 ： 一個銀行網站在 login 的按鈕上被壞傢伙藏一個看不見的 iframe ， 另外 Clickhijacking 也可能被藏在看得見的元件上 ， 這做法讓 user 實際上進入完全不如預期的頁面或行為 。
  為了防禦 Clickhijacking ， 網站可以在 appropriate HTTP headers 設定避免嵌入其他網站來的 iframe
• DoS
  Denial of Service ， 在網站夾帶假 req ， 導致 user 存取權限被破壞 ， 這個 req 可能很大量 ， 或著各別消耗掉大量 resource ( 讀取緩慢或上傳大量檔案 ) 。
  防禦方面通常藉由辨識流量並擋住異常流量 。 這類防護在 server 很普通 ( 它們並非 web app 本身的一部分 )
• Directory Traversal
  ( traversal 遊歷的意思 ) 試圖進入原本不該被進入的 server file system ， 這個漏洞會發生在 user 能夠傳遞包含系統錨點字元的檔案命名時 ( 例如 ../../ ) 。 解法是禁用那類的命名
• File Inclusion
  指定一個 「 非故意的 」檔案傳到 server 去 ， 成功上傳後 ， 這個檔案可能會在 ss 被執行 ， 也可能在 cs ( 去觸發 XSS ) ， 解法是禁用 ( 蛤？什麼非故意檔案 )
• Command Injection
  執行主系統上其他任意系統的 command 。 解法是在系統調用前禁用

更全面的攻擊行為可以參考
Category: Web security exploits ( 維基百科 )
Category: Attack ( web app 安全計畫 )

筆者的後記

下一篇會把網站安全這整頁做總結 ， 就要進入 Express 框架的世界了 ， 終於！！
補充新聞閱讀 ： 企業弱密碼今年狂被駭！HITCON資安漏洞申報平台連台電、群暉都拜託「抓漏」 數位時代